해외에 서비스를 제공시 번역에 관한 고민

해외에 서비스를 제공하며 느꼈던 번역에 대한 불편한점

• 번역에 관해서는 회사마다 각자 다른 방식을 통해서 제공하고 있을것으로 예상된다. 최근까지 재직했었던 회사에서 최근에 번역에 관해서 개발자들끼리 불편함을 느끼고있었고 그것에 관한 해결법을 논의하면서 방법을 찾아보고 번역하는 방식을 바꾸는 작업에 참여했었다.
• 참고로 이전에 재직했었던 회사는 translation을 json형태의 파일로 public폴더에 넣어놓고 사용하는 방식으로 되어있었다. 번역이 추가되면 직접 개발자가 이 json 파일에 추가하거나 수정하는 방식으로 개발되었다.
• 불편함을 느낀 포인트
  • 정확한 번역을 봐야하는곳이 명확하게 정해져있지 않았다. 어떤 경우에는 Figma를 보고 작업해야했고 어떤 경우에는 Jira 카드에 들어가 있는 경우도 있었고 또 어떤 경우에는 confluence에 있는 경우도 있었다. 정해진 규칙이 없다보니 매번 어떤 번역을 보고 해야하는지 찾는데 시간이 소요되는 경우가 자주 있었음
  • 개발을 끝내고나서 qa중에 번역만 바뀐 경우가 있거나 누군가의 실수로 번역이 잘못 들어갔을 경우에는 또 새롭게 수정해서 pr올리고 리뷰받고 dev에 올려놓고 다시 qa로 올려서 새로 qa에 배포하고 하는 이런 과정을 거쳐야했어서 매우 불편한 부분이 있었다.
  • 그리고 번역이 아직 나오지 않아서 작업을 못끝내는 경우도 존재하였고 정확히 ux writer분이 계시지 않을때 또 누군가를 하염없이 기다리는..그런일도 있었다. PO분이나 디저이너분에게 이거 번역 언제나오죠? 물어보는 경우도 많이있었고 서로에게 방해가 되는 부분으로 느껴졌었다.

당시 팀에서 해결하고자 했던 방향

• 당시 팀내에서 리드 및 시니어 개발자분들과 PO분과 함께 몇 차례에 걸쳐서 미팅을 진행하였고 우리가 해결하고자 하는 목표와 불편함에 대해서 정의하고 어떤식으로 할지를 정하였었다.

• 우리가 해결하고자 했었던 방향

  • 번역은 개발자가 크게 신경쓰지 않아도 개발하는데 문제가 없어야한다. (편의성)
  • 번역은 UX writer분과 디자이너분들의 영역으로 제한하고 그 분들이 수정하는 방식으로 한다. (보안성)
  • ux writer분 및 디자이너분들이 수정했을시에 각 개발환경에서 바로 사용할 수 있도록 되어야한다. 하지만 그렇다고 번역파일을 수정했을때 바로 라이브 환경에 영향을 주도록 하는것은 안된다.(실시간성)

• 이정도의 불편함을 해결하자는 결론이 도출되었고 어떤식으로 작업을 진행할지 정하였다. 우선 우리는 번역파일을 google sheet를 사용해서 관리하도록 결정하였고 google sheet를 json형태로 받아와서 사용하는 방식으로 진행하기로 하였다.

번역의 스트레스에서 벗어나보기

• 생각보다 번역방식을 바꾸는건 빠르게 진행되었다. 우선 내가 google sheet를 받아오고 작성할 수 있는 스크립트를 만드는걸 담당했었고 리드 개발자 한 분이 이걸 cdn으로 배포해서 사용하는 방식으로 변경할 수 있도록 배포쪽을 담당해주셔서 봐주셨다. 그리고 추가적으로 캐싱처리는 우선 캐싱 타임을 0으로 설정해놓고 그때그때 새로운 파일이 올라왔을때 바로 반영될 수 있도록 만들었던걸로 기억한다. 그리고 google sheet를 수정하고나서 새로 deploy할 수 있도록 ux writer분과 디자이너분을 위한 publishing용으로 간단한 app을 만들어서 사용하기로 하고 여기서 dev,qa,staging 과 live 2가지로 각각 분리되서 배포할 수 있도록 버튼을 만들어놓았다.

• 간략하게 번역 프로세스 요약

  • dev,qa,staging 과 live 각각 분리하여 cdn으로 내가 만든 스크립트 파일을 실행시켜서 json파일을 만들어서 올려놓는다.
  • 만약 번역이 새롭게 추가 및 수정후 publishing용 사이트에서 환경별로 버튼을 눌러 publish하면 각 환경에 맡게 최신의 google sheet 내용을 json형태로 가져와서 cdn에 새롭게 배포한다. (이때 캐싱되었을경우 새로 반영된걸 못볼수있어서 우선 캐싱타임을 0으로 설정해놓았음)
  • 우선 간단하게 요약하자면 이정도 프로세스이다. google sheet 수정 권한은 ux writer분과 디자이너분들께 우선 드리는걸로하고 수정후 각 환경별로 유의해서 퍼블리싱을 해야한다는걸 공유해드리는 정도만 공유드리면 되었다.

• script를 만들었던 방식

  • google spreadsheet (https://developers.google.com/sheets/api)와 라이브러리(https://github.com/theoephraim/node-google-spreadsheet)를 사용해서 개발을 진행했었고 사용하기전에 credentials를 몇가지 준비해야 했었다. 우선 GCP에서 서비스 계정을 생성하고 api키와 credentials를 json형태의 키로 발급받아 이 값으로 연결해주어야했고 연결하는건 생각보다 문서에 잘 작성되어 있어서 간단했었다.

변경하고나서 후기

• 아쉽게 만들어진 후에 상당히 짧은 기간밖에 사용해보지 못했지만 확실히 이전보다 많이 편리했던것은 맞았고 우리가 해결하고자 했던 문제점들은 해결되었던것 같다. 사실 번역과 관련해서는 i18n 라이브러리를 굉장히 많이 사용하는데 당장 이걸 추가하기에는 신경써야할 사이드 이펙트들이 많았다고 판단되어서 다른 방식으로 새로운 번역기능을 도입했었는데 우리에게 필요한 방식으로 적재적소에 맡게 적절한 기술들을써서 해결했던것 같은 좋은 경험이였다. best practice일지에 대해선 의심해보아야 하지만 다음에 비슷한 경우가있다면 이런 경우도 있었다는 좋은 경험으로 남을것 같다. 재미있는 문제해결 과정이 였었다 !